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Abstract 


YANG is a data modeling language used to model configuration and 
state data manipulated by the Network Configuration Protocol 
(NETCONF), NETCONF remote procedure calls, and NETCONF notifications. 
The Structure of Management Information (SMIv2) defines fundamental 
data types, an object model, and the rules for writing and revising 
MIB modules for use with the Simple Network Management Protocol 
(SNMP). This document defines a translation of SMIv2 MIB modules 
into YANG modules, enabling read-only (config false) access to data 
objects defined in SMIv2 MIB modules via NETCONF. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6643. 
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Les 


Introduction 


This document describes a translation of SMIv2 [RFC2578], [RFC2579], 
[RFC2580] MIB modules into YANG [RFC6020] modules, enabling read-only 
(config false, as defined in Section 7.19.1 of RFC 6020) access to 
SMIv2 objects defined in SMIv2 MIB modules via NETCONF [RFC6241]. 

For a discussion why SMIv2 read-write or read-create objects are 
translated to read-only (config false) YANG objects, see Section 11. 


YANG modules generated from SMIv2 modules should not be modified. 

Any necessary changes should be made by modifying the original SMIv2 
modules (with proper updates of the SMIv2 LAST-UPDATED and REVISION 
clauses) and then running the translation defined in this memo again. 
Note that this does not affect the usage of YANG augments and or YANG 
deviations: YANG modules generated from SMIv2 modules can be 
augmented like any other YANG module, and YANG deviations can be used 
to document how an implementation deviates from the generated YANG 
module. 


SMIv1 modules can be converted to YANG by first following the rules 
in [RFC3584] to convert the SMIv1 module to SMIv2 and then following 
the rules in this document to convert the obtained SMIv2 module to 
YANG. 


The SMIv2-to-YANG mapping is illustrated by examples showing the 
translation of parts of the IF-MIB [RFC2863], the DIFFSERV-MIB 
[RFC3289], and the RMON2-MIB [RFC4502] SMIv2 modules. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in BCP 
14 [RFC2119]. 


Mapping of Well-Known Types 


The SMIv2 base types and some well-known derived textual conventions 
are mapped to YANG types according to Appendix A. The mapping of the 
OCTET STRING depends on the context. If an OCTET STRING type has an 
associated DISPLAY-HINT, then the corresponding YANG base type is the 
string type. An implementation MUST format an OCTET STRING value 
according to the DISPLAY-HINT, as described in RFC 2579. If an 
OCTECT STRING type does not have an associated DISPLAY-HINT, the 
binary type is used. Similarly, the mapping of the INTEGER type 
depends on its usage as an enumeration or a 32-bit integral type. 
Implementations should provide implementation-specific options to 
handle situations where DISPLAY- HINTs are added during a revision of 
a module and backwards compatibility must be preserved, i.e., an 
added DISPLAY-HINT needs to be ignored. 
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The mappings shown in Appendix A may require to import the ietf-yang- 
types, ietf-inet-types, or ietf-yang-smiv2 YANG modules since some 
SMIv2 types and textual conventions map to YANG types defined in the 
ietf-yang-types and ietf-inet-types YANG modules defined in [RFC6021] 
and the ietf-yang-smiv2 YANG module defined in this document. 
Implementations MUST add any additional imports required by the type 
mapping. 


3. Translation of SMIv2 Modules and SMIv2 IMPORT Clauses 


SMIv2 modules are mapped to corresponding YANG modules. The 
generated YANG module name MUST be the same as the SMIv2 module name. 


The YANG namespace MUST be constructed out of the IANA-registered 
prefix urn:ietf:params:xml:ins:yang:smiv2: (see Section 12) followed 
by the SMIv2 module name. Since SMIv2 module names can be assumed to 
be unique (see Section 3 in [RFC2578]), the resulting YANG namespace 
is unique. 


The YANG prefix MAY be derived from the SMIv2 module name using the 
module prefix generation algorithm described in Appendix B. The YANG 
prefix is supposed to be short, and it must be unique within the set 
of all prefixes used by a YANG module. The algorithm described in 
Appendix B generates such prefixes. 


SMIv2 IMPORT clauses are translated to YANG import statements. One 
major difference between the SMIv2 import mechanism and the YANG 
import mechanism is that SMIv2 IMPORT clauses import specific symbols 
from an SMIv2 module, while the YANG import statement imports all 
symbols of the referenced YANG module. 


In order to produce correct and complete YANG import statements, the 
following rules MUST be used: 


o Process each item in each SMIv2 IMPORT clause as follows: 


1. If an import statement for this SMIv2 module has already been 
generated, then ignore this item. 


2. Otherwise, if the SMIv2 module name is SNMPv2-SMI or SNMPv2- 
CONF, then ignore this item. Note that these two modules can 
be completely ignored since all definitions in these modules 
are translated by translation rules. 


3. Otherwise, if this item is a textual convention matching one 
of the textual conventions in the SMIv2 types column of 
Appendix A (e.g., MacAddress, PhysAddress, or TimeStamp) then 
ignore this item. 
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4. Otherwise, if the item is used in a SYNTAX clause of an 
OBJECT-TYPE whose MAX-ACCESS is not accessible-for-notify, 
then generate an import statement as described below. 


5. Otherwise, if the item is used in an OBJECTS clause of a 
NOTIFICATION-TYPE, then generate an import statement as 
described below. 


6. Otherwise, if the item is used in an INDEX or AUGMENTS clause, 
then generate an import statement as described below. 


7. Otherwise, ignore this item. Some examples of this case are 
OBJECT IDENTIFIER assignments and objects that are only 
referenced in MODULE-COMPLIANCE, OBJECT-GROUP, or 
NOTIFICATION-GROUP clauses. 


o Generate any additional import statements as required by the type 
translations according to the type mapping table Appendix A. This 
requires the translator to consider all the types used in the 
SMIv2 module in order to produce the imports. 


o Generate an import statement for the YANG module ietf-yang-smiv2 
with the prefix smiv2. 


The generated import statements use the untranslated SMIv2 module 
names or the names of well-known YANG modules as their argument. The 
import statement must contain a prefix statement. The prefixes MAY 
be generated by applying the module prefix generation algorithm 
described in Appendix B. 


3.1. Example: IMPORTS of IF-MIB 


The translation of the IF-MIB [RFC2863] leads to the YANG module and 
namespace/prefix statement and the import statements shown below. 
The prefix is the translation of the SMIv2 module name IF-MIB to 
lowercase (consisting of two tokens and thus no further 
abbreviation). 


module IF-MIB { 


namespace "urn:ietf:params:xml:ns:yang:smiv2:IF-MIB"; 
prefix "if-mib"; 


import IANAifType-MIB { prefix "ianaiftype-mib"; } 
import SNMPv2-TC { prefix "snmpv2-tc"; } 
import ietf-yang-types { prefix "yang"; } 

import ietf-yang-smiv2 { prefix "smiv2"; } 
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4. 


Translation of the MODULE-IDENTITY Macro 


SMIv2 requires an invocation of the MODULE-IDENTITY macro to provide 
contact and revision history for a MIB module. The clauses of the 
SMIv2 MODULE-IDENTITY macro MUST be translated into YANG statements 
as detailed below. 


MODULE-IDENTITY Translation Rules 


o The SMIv2 ORGANIZATION clause is mapped to the YANG organization 
statement. 


o The SMIv2 CONTACT-INFO clause is mapped to the YANG contact 
statement. 


o The SMIv2 DESCRIPTION clause is mapped to the YANG description 
statement. 


o Each SMIv2 REVISION clause is mapped to a YANG revision statement. 
The revision is identified by the date argument of the SMIv2 
REVISION clause. DESCRIPTION sub-clauses of REVISION clauses are 
mapped to corresponding description statement nested in revision 
clauses. 


o The SMIv2 LAST-UPDATED clause is ignored if the associated date 
matches a REVISION clause. Otherwise, an additional revision 
statement is generated. 


o A top-level YANG container is generated. The container’s name is 
the SMIv2 module name, and the container MUST be config false. 
The generation of the top-level container MAY be skipped if the 
SMIv2 module does not define any objects that go into the top- 
level container (e.g., an SMIv2 module only defining textual 
conventions). 


o The object identifier value of the invocation of the SMIv2 MODULE- 
IDENTITY is translated into an smiv2:oid statement contained in an 
smiv2:alias statement representing the MODULE-IDENTITY macro 
invocation. Refer to the YANG extension defined in Section 10. 


While all proper SMIv2 modules must have exactly one MODULE-IDENTITY 
macro invocation, there are a few notable exceptions. The modules 
defining the SMIv2 language (i.e., the SNMPv2-SMI, SNMPv2-TC, and 
SNMPv2-CONF modules) do not invoke the MODULE-IDENTITY macro. 
Furthermore, SMIv2 modules generated from SMIv1 modules may miss an 
invocation of the MODULE-IDENTITY macro as well. In such cases, it 
is preferable to not generate organization, contact, description, or 
revision statements. 
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4.2. Example: MODULE-IDENTITY of IF-MIB 


The translation of the MODULE-IDENTITY of the IF-MIB [RFC2863] leads 
to the following YANG statements: 


organization 
"IETF Interfaces MIB Working Group"; 


contact 
"Keith McCloghrie 
Cisco Systems, Inc. 
170 West Tasman Drive 
San Jose, CA 95134-1706 
US 


408-526-5260 
kzm@cisco.com"; 


description 
"The MIB module to describe generic objects for network 
interface sub-layers. This MIB is an updated version of 
MIB-II’s ifTable, and incorporates the extensions defined in 
RFC 1229."; 


revision "2000-06-14" { 
description 
"Clarifications agreed upon by the Interfaces MIB WG, and 
published as RFC 2863."; 
} 
revision "1996-02-28" { 
description 
"Revisions made by the Interfaces MIB WG, and published in 
REG 2233: "3 
} 
revision "1993-11-08" { 
description 
"Initial revision, published as part of RFC 1573."; 
} 


container IF-MIB { 


config false; 
} 
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3% 


Translation of the TEXTUAL-—CONVENTION Macro 


The SMIv2 uses invocations of the TEXTUAL-CONVENTION macro to define 
new types derived from the SMIv2 base types. Invocations of the 
TEXTUAL-CONVENTION macro MUST be translated into YANG typedef 
statements as detailed below. 


Fole 


TEXTUAL-CONVENTION Translation Rules 


The name of the TEXTUAL-CONVENTION macro invocation is used as the 
name of the generated typedef statement. The clauses of the SMIv2 
TEXTUAL-CONVENTION macro are mapped to YANG statements embedded in 
the typedef statement as follows: 


(0) 


The SMIv2 DISPLAY-HINT clause is used to determine the type 
mapping of types derived form the OCTET STRING type as explained 
in Section 2. Furthermore, the DISPLAY-HINT value MAY be used to 
generate a regular expression for the YANG pattern statement 
within the type statement. 


The SMIv2 DISPLAY-HINT is translated into an smiv2:display-hint 
statement. Refer to the YANG extension defined in Section 10. 


The SMIv2 STATUS clause is mapped to the YANG status statement. 
The generation of the YANG status statement is skipped if the 
value of the STATUS clause is current. 


The SMIv2 DESCRIPTION clause is mapped to the YANG description 
statement. 


The SMIv2 REFERENCE clause is mapped to the YANG reference 
statement. 


The SMIv2 SYNTAX clause is mapped to the YANG type statement. 
SMIv2 range restrictions are mapped to YANG range statements, 
while SMIv2 length restrictions are mapped to YANG length 
statements. SMIv2 INTEGER enumerations are mapped to YANG enum/ 
value statements. SMIv2 BITS are mapped to YANG bit/position 
statements. For OCTET STRING types that are mapped to a YANG 
string base type (see Section 2), the length specified in the YANG 
length statement must be consistent with the stringified 
representation of values. If an implementation is unable to 
derive a proper length restrictions, then the YANG length 
statement MUST be omitted. 
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This translation assumes that labels of named numbers and named bits 
do not change when an SMIv2 module is revised. This is consistent 
with the clarification of the SMIv2 module revision rules in Section 
4.9 of [RFC4181]. 


5.2. Example: OwnerString and InterfaceIndex of IF-MIB 


The translations of the OwnerString and InterfaceIndex textual 
conventions of the IF-MIB [RFC2863] are shown below. 


typedef OwnerString { 
type string { 
length "0..255"; 
pattern ’\p{IsBasicLatin}{0,255}’; 
} 


status deprecated; 


description 
"This data type is used to model an administratively 
assigned name of the owner of a resource. This information 


is taken from the NVT ASCII character set. It is suggested 
that this name contain one or more of the following: ASCII 
form of the manager station’s transport address, management 
station name (e.g., domain name), network management 
personnel’s name, location, or phone number. In some cases 
the agent itself will be the owner of an entry. In these 
cases, this string shall be set to a string starting with 
‘agent’ ."; 
smiv2:display-hint "255a"; 
} 


typedef InterfaceIndex { 

type int32 { 
range "1..2147483647"; 

} 

description 
"A unique value, greater than zero, for each interface or 
interface sub-layer in the managed system. It is 
recommended that values are assigned contiguously starting 
from 1. The value for each interface sub-layer must remain 
constant at least from one re-initialization of the entity’s 
network management system to the next re-initialization."; 

smiv2:display-hint "d"; 
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Is 


6. 


7. 


3. Example: IfDirection of the DIFFSERV-MIB 


The translation of the IfDirection textual convention of the 
DIFFSERV-MIB [RFC3289] is shown below. 


typedef IfDirection { 

type enumeration { 
enum inbound { value 1; } 
enum outbound { value 2; } 

} 

description 
"IfDirection specifies a direction of data travel on an 
interface. /’inbound’ traffic is operated on during reception 
from the interface, while ’outbound’ traffic is operated on 
prior to transmission on the interface."; 


} 


Translation of OBJECT IDENTIFIER Assignments 


The SMIv2 uses OBJECT IDENTIFIER assignments to introduce names for 
intermediate nodes in the OBJECT IDENTIFIER tree. OBJECT IDENTIFIER 
assignments are translated into smiv2:alias statements. Refer to the 
YANG extension defined in Section 10. 


Translation of the OBJECT-TYPE Macro 


The SMIv2 uses the OBJECT-TYPE macro to define objects and the 
structure of conceptual tables. Objects exist either as scalars 
(exactly one instance within an SNMP context) or columnar objects 
within conceptual tables (zero or multiple instances within an SNMP 
context). A number of auxiliary objects define the index (key) of a 
conceptual table. Furthermore, conceptual tables can be augmented by 
other conceptual tables. All these differences must be taken into 
account when translating SMIv2 OBJECT-TYPE macro invocations to YANG. 
Invocations of the OBJECT-TYPE macro MUST be translated into YANG 
statements as detailed below. 


1. Scalar and Columnar Object Translation Rules 


SMIv2 OBJECT-TYPE macro invocations defining scalars or columnar 
objects with a MAX-ACCESS of "not-accessible", "read-only", 
"read-write", and "read-create" are translated to YANG leaf 
statements. Additionally, columnar objects with a MAX-ACCESS of 
"accessible-for-notify" are translated to YANG leaf statements if 
that columnar object is part of the INDEX clause of the table 
containing that columnar object. The name of the leaf is the name 
associated with the SMIv2 OBJECT-TYPE macro invocation. SMIv2 
OBJECT-TYPE macro invocations with a MAX-ACCESS of 
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"accessible-for-notify" are not translated to YANG data tree leafs 
but instead are translated into YANG notification leafs. 


Leaf statements for scalar objects are created in a container 
representing the scalar’s parent node in the OID tree. This 
container is named after the scalar’s parent node in the OID tree and 
placed in the top-level container representing the SMIv2 module; see 
Section 4.1. In the rare case that the scalar’s parent node has 
multiple names, the automatic translation MUST fail with an error, 
and the name clash needs to be investigated and fixed manually. In 
case a previous revision of the SMIv2 module did not have an 
ambiguity, then the name used by the previous revision MUST be used. 
The leaf statements representing columnar objects are created in the 
list representing a conceptual row; see Section 7.3. 


o The SMIv2 SYNTAX clause is mapped to the YANG type statement. 
SMIv2 range restrictions are mapped to YANG range statements, 
while SMIv2 length restrictions are mapped to YANG length 
statements. SMIv2 INTEGER enumerations are mapped to YANG enum/ 
value statements. SMIv2 BITS are mapped to YANG bit/position 
statements. For OCTET STRING types that are mapped to a YANG 
string base type (see Section 2), the length specified in the YANG 
length statement must be consistent with the stringified 
representation of values. If an implementation is unable to 
derive proper length restrictions, then the YANG length statement 
MUST be omitted. 


o The SMIv2 UNITS clause is mapped to the YANG units statement. 


o The SMIv2 MAX-ACCESS is translated into an smiv2:max-access 
statement. Refer to the YANG extension defined in Section 10. 


o The SMIv2 STATUS clause is mapped to the YANG status statement. 
The generation of the YANG status statement is skipped if the 
value of the STATUS clause is current. 


o The SMIv2 DESCRIPTION clause is mapped to the YANG description 
statement. 


o The SMIv2 REFERENCE clause is mapped to the YANG reference 
statement. 


o The SMIv2 DEFVAL clause is mapped to an smiv2:defval statement. 
Refer to the YANG extension defined in Section 10. 


o The value of the SMIv2 OBJECT-TYPE macro invocation is translated 


into an smiv2:oid statement. Refer to the YANG extension defined 
in Section 10. 
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This translation assumes that labels of named numbers and named bits 
do not change when an SMIv2 module is revised. This is consistent 
with the clarification of the SMIv2 module revision rules in Section 
4.9 of [RFC4181]. 


7.2. Example: ifNumber and ifIndex of the IF-MIB 


The translations of the ifNumber scalar object and the ifIndex 
columnar object of the IF-MIB [RFC2863] are shown below. Since 
ifNumber is a scalar object in the interfaces branch of the IF-MIB, 
the YANG leaf ifNumber will be placed in a YANG container called 
interfaces, which is registered in the top-level container IF-MIB. 


leaf ifNumber { 
type int32; 
description 
"The number of network interfaces (regardless of their 
current state) present on this system."; 
smiv2:max-access "read-only"; 
smiv2sord "1.3.6.1.2.1.2.177 
} 


leaf ifIndex { 

type if-mib:InterfaceIndex; 

description 
"A unique value, greater than zero, for each interface. It 
is recommended that values are assigned contiguously 
starting from 1. The value for each interface sub-layer 
must remain constant at least from one re-initialization of 
the entity’s network management system to the next re- 
initialization."; 

smiv2:max-access "read-only"; 

Smiv2: O10) “1.3°..6eLe2ete 22 sty 


7.3. Non-Augmenting Conceptual Table Translation Rules 
An OBJECT-TYPE macro invocation defining a non-augmenting conceptual 
table is translated to a YANG container statement using the name of 
the OBJECT-TYPE macro invocation. This container is created in the 
top-level container representing the SMIv2 module. The clauses of 
the macro are translated as follows: 
o The SMIv2 SYNTAX clause is ignored 


o The SMIv2 UNITS clause is ignored. 


o The SMIv2 MAX-ACCESS clause is ignored. 
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The SMIv2 STATUS clause is mapped to the YANG status statement. 
The generation of the YANG status statement is skipped if the 
value of the STATUS clause is current. 


The SMIv2 DESCRIPTION clause is mapped to the YANG description 
statement. 


The SMIv2 REFERENCE clause is mapped to the YANG reference 
statement. 


The value of the SMIv2 OBJECT-TYPE macro invocation is translated 
into an smiv2:oid statement. Refer to the YANG extension defined 
in Section 10. 


An OBJECT-TYPE macro invocation defining a conceptual row is 
translated to a YANG list statement. It is contained in the YANG 
container representing the conceptual table. The generated list uses 
the name of the row OBJECT-TYPE macro invocation. The clauses of the 
OBJECT-TYPE macro are translated as follows: 


(0) 


(0) 


The SMIv2 SYNTAX clause is ignored. 
The SMIv2 UNITS clause is ignored. 
The SMIv2 MAX-ACCESS clause is ignored. 


The SMIv2 STATUS clause is mapped to the YANG status statement. 
The generation of the YANG status statement is skipped if the 
value of the STATUS clause is current. 


The SMIv2 DESCRIPTION clause is mapped to the YANG description 
statement. 


The SMIv2 REFERENCE clause is mapped to the YANG reference 
statement. 


The SMIv2 INDEX clause is mapped to the YANG key clause listing 
the columnar objects forming the key of the YANG list. If the 
same object appears more than once in the INDEX clause, append 
’_<n>’ to the duplicate object name(s) where ’<n>’ counts the 
occurrences of the object in the INDEX clause, starting from 2. 
Additional leaf statements must be created to define the leafs 
introduced. 


If the SMIv2 INDEX clause contains the IMPLIED keyword, then an 
smiv2:implied statement is generated to record the name of the 
object preceded by the IMPLIED keyword. Refer to the YANG 
extension defined in Section 10. 
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o The value of the SMIv2 OBJECT-TYPE macro invocation is translated 
into an smiv2:oid statement. Refer to the YANG extension defined 
in Section 10. 


Within the list statement, YANG leaf statements are created for 
columnar objects as described in Section 7.1. For objects listed in 
the SMIv2 INDEX clause that are not part of the conceptual table 
itself, YANG leaf statements of type leafref pointing to the 
referenced definition are created. 


7.4. Example: ifTable of the IF-MIB 


The translation of the definition of the ifTable of the IF-MIB 
[RFC2863] is shown below. 


container ifTable { 
description 
"A list of interface entries. The number of entries is 
given by the value of ifNumber."; 
smiv2:ord, “41.38.6211, 2.422.2"3 


list ifEntry { 
key "ifIndex"; 
description 
"An entry containing management information applicable to a 
particular interface."; 
SmI ord: "17.3561 e251 222315 


leaf ifIndex { 
type if-mib:InterfaceIndex; 
description 
"A unique value, greater than zero, for each interface. It 
is recommended that values are assigned contiguously 
starting from 1. The value for each interface sub-layer 
must remain constant at least from one re-initialization of 
the entity’s network management system to the next re- 
initialization."; 
smiv2:max-access "read-only"; 
smiv2soid: "13601. 20 e222. Ls; 
} 


// 
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7.5. Example: ifRcvAddressTable of the IF-MIB 


The translation of the definition of the ifRcvAddressTable of the 
IF-MIB [RFC2863] is shown below. 


container ifRcvAddressTable { 
description 
"This table contains an entry for each address (broadcast, 
multicast, or uni-cast) for which the system will receive 
packets/frames on a particular interface, except as follows: 


- for an interface operating in promiscuous mode, entries are 
only required for those addresses for which the system would 
receive frames were it not operating in promiscuous mode. 


- for 802.5 functional addresses, only one entry is required, 
for the address which has the functional address bit ANDed 
with the bit mask of all functional addresses for which the 
interface will accept frames. 


A system is normally able to use any unicast address which 
corresponds to an entry in this table as a source address."; 
Smiv2 ord V1.3, dD Seas 


list ifRcvAddressEntry { 
key "ifIndex ifRcvAddressAddress"; 
description 
"A list of objects identifying an address for which the 
system will accept packets/frames on the particular 
interface identified by the index value ifIndex."; 
smiv2 soid: "L230. 1221.31.12. 4 3s 


leaf ifIndex { 
type leafref { 
path "/if-mib:IF-MIB/if-mib:ifTable" + 
"/if-mib:ifEntry/if-mib:ifIndex"; 


} 


leaf ifRcvAddressAddress { 
type yang:phys-address; 
description 
"An address for which the system will accept packets/frames 
on this entry’s interface."; 
smiv2:max-access "not-accessible"; 
smiv2 oid "136 gle Beles Asal Ls 


Schoenwaelder Standards Track [Page 16] 


RFC 6643 Translation of SMIv2 to YANG July 2012 


// 


7.6. Example: alHostTable of the RMON2-MIB 


The translation of the definition of the alHostTable of the RMON2-MIB 
[RFC4502] is shown below. 


container alHostTable { 
description 
"A collection of statistics for a particular protocol from a 
particular network address that has been discovered on an 
interface of this device. 


The probe will populate this table for all protocols in the 
protocol directory table whose value of 
protocolDirHostConfig is equal to supportedOn(3), and 

will delete any entries whose protocolDirEntry is deleted or 
has a protocolDirHostConfig value of supportedOff(2). 


The probe will add to this table all addresses 
seen as the source or destination address in all packets with 
no MAC errors and will increment octet and packet counts in 
the table for all packets with no MAC errors. Further, 
entries will only be added to this table if their address 
exists in the nlHostTable and will be deleted from this table 
if their address is deleted from the nlHostTable."; 

smiv2s0id. "1.3.6.1.2.1.16.16.1"; 


list alHostEntry { 
key "hlHostControlIndex alHostTimeMark protocolDirLocalIndex " 
+ "nlHostAddress protocolDirLocalIndex_2"; 
description 
"A conceptual row in the alHostTable. 


The hlHostControlIndex value in the index identifies the 
hlHostControlEntry on whose behalf this entry was created. 

The first protocolDirLocalIndex value in the index identifies 
the network-layer protocol of the address. 

The nlHostAddress value in the index identifies the network- 
layer address of this entry. 

The second protocolDirLocalIndex value in the index identifies 
the protocol that is counted by this entry. 


An example of the indexing in this entry is 
alHostOutPkts.1.783495.18.4.128.2.6.6.34. 
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Seel a 


Note that some combinations of index values may result in an 
index that exceeds 128 sub-identifiers in length, which exceeds 
the maximum for the SNMP protocol. Implementations should take 
care to avoid such combinations."; 

smiv2:oid "1.3.6.1.2.1.16.16.1.1"; 


// 


leaf protocolDirLocalIndex { 
type leafref { 
path "/rmon2-mib:RMON2-MIB/" 
+ "rmon2-mib:protocolDirTable/" 
+ "rmon2-mib:protocolDirEntry/" 
+ "rmon2-mib:protocolDirLocalIndex"; 


} 
// 


leaf protocolDirLocalIndex_2 { 
type leafref { 
path "/rmon2-mib:RMON2-MIB/" 
+ "rmon2-mib:protocolDirTable/" 
+ "rmon2-mib:protocolDirEntry/" 
+ "rmon2-mib:protocolDirLocalIndex"; 


// 


Augmenting Conceptual Tables Translation Rules 


An OBJECT-TYPE macro invocation defining an augmenting conceptual 
table is translated to a YANG smiv2:alias statement. Refer to the 
YANG extension defined in Section 10. The clauses of the macro are 
translated as follows: 


(0) 


(0) 


The SMIv2 SYNTAX clause is ignored. 

The SMIv2 UNITS clause is ignored. 

The SMIv2 MAX-ACCESS clause is ignored. 

The SMIv2 STATUS clause is mapped to the YANG status statement. 


The generation of the YANG status statement is skipped if the 
value of the STATUS clause is current. 
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o The SMIv2 DESCRIPTION clause is mapped to the YANG description 
statement. 


o The SMIv2 REFERENCE clause is mapped to the YANG reference 
statement. 


o The value of the SMIv2 OBJECT-TYPE macro invocation is translated 
into an smiv2:oid statement. Refer to the YANG extension defined 
in Section 10. 


An OBJECT-TYPE macro invocation defining a conceptual row 
augmentation is translated to a YANG smiv2:alias statement and a YANG 
augment statement using the path to the augmented table as its 
argument. The clauses of the OBJECT-TYPE macro are translated as 
follows: 


o The SMIv2 SYNTAX clause is ignored. 

o The SMIv2 UNITS clause is ignored. 

o The SMIv2 MAX-ACCESS clause is ignored. 

o The SMIv2 STATUS clause is mapped to the YANG status statement. 
The generation of the YANG status statement is skipped if the 


value of the STATUS clause is current. 


o The SMIv2 DESCRIPTION clause is mapped to the YANG description 
statement. 


o The SMIv2 REFERENCE clause is mapped to the YANG reference 
statement. 


o The value of the SMIv2 OBJECT-TYPE macro invocation is translated 
into an smiv2:oid statement. Refer to the YANG extension defined 


in Section 10. 


Within the augment statement, YANG leaf statements are created as 
described in Section 7.1. 
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7.8. Example: ifXTable of the IF-MIB 


The translation of the definition of the ifXTable of the IF-MIB 
[RFC2863] is shown below. 


smiv2:alias "ifXTable" { 
description 
"A list of interface entries. The number of entries is 
given by the value of ifNumber. This table contains 
additional objects for the interface table."; 
smiv2:oid "1.3.6.1.2.1.31.1.1"; 
} 


smiv2:alias "ifXEntry" { 
description 
"An entry containing additional management information 
applicable to a particular interface."; 
smiv2:oid "1.3.6.1.2.1.31.1.1.1"; 
} 


augment "/if-mib:IF-MIB/if-mib:ifTable/if-mib:ifEntry" { 
description 
"An entry containing additional management information 
applicable to a particular interface."; 
smirý2 oid "1.300142 1.43111; 


leaf ifName { 
type snmpv2-tc:DisplayString; 
description 
"The textual name of the interface. The value of this 
object should be the name of the interface as assigned by 
the local device and should be suitable for use in commands 
entered at the device’s ‘console’. This might be a text 
name, such as ‘le0’ or a simple port number, such as ‘1’, 
depending on the interface naming syntax of the device. If 
several entries in the ifTable together represent a single 
interface as named by the device, then each will have the 
same value of ifName. Note that for an agent which responds 
to SNMP queries concerning an interface on some other 
(proxied) device, then the value of ifName for such an 
interface is the proxied device’s local name for it. 


If there is no local name, or this object is otherwise not 
applicable, then this object contains a zero-length string."; 
smiv2:max-access "read-only"; 
smiv2sord "13.06.1109 133040 Td 
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8. 


8. 


// 
} 


Translation of the OBJECT-IDENTITY Macro 


The SMIv2 uses invocations of the OBJECT-IDENTITY macro to define 
information about an OBJECT IDENTIFIER assignment. Invocations of 
the OBJECT-IDENTITY macro MUST be translated into YANG identity 
statements as detailed below. 


OBJECT-IDENTITY Translation Rules 


The name of the OBJECT-IDENTITY macro invocation is used as the name 
of the generated identity statement. The generated identity 
statement uses the smiv2:object-identity defined in Section 10 as its 
base. The clauses of the SMIv2 OBJECT-IDENTITY macro are mapped to 
YANG statements as follows: 


o The SMIv2 STATUS clause is mapped to the YANG status statement. 
The generation of the YANG status statement is skipped if the 
value of the STATUS clause is current. 


o The SMIv2 DESCRIPTION clause is mapped to the YANG description 
statement. 


o The SMIv2 REFERENCE clause is mapped to the YANG reference 
statement. 


o The value of the SMIv2 OBJECT-IDENTITY macro invocation is 
translated into an smiv2:oid statement. Refer to the YANG 
extension defined in Section 10. 


Example: diffServIBParamSimpleTokenBucket of the DIFFSERV-MIB 


The translation of the diffServTBParamSimpleTokenBucket of the 
DIFFSERV-MIB [RFC3289] is shown below. (Please note that the 
description should refer to RFC 3290, Section 5.1.3.) 


identity diffServTBParamSimpleTokenBucket { 
base "sSmiv2:object-identity"; 
description 
"Two Parameter Token Bucket Meter as described in the Informal 
Differentiated Services Model section 5.2.3."; 
smiv23old MII Gs Ias 1597.31 
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Ds 


9. 


Translation of the NOTIFICATION-TYPE Macro 


SMIv2 provides the NOTIFICATION-TYPE macro to define event 
notifications. YANG provides the notification statement for the same 
purpose. Invocations of the NOTIFICATION-TYPE macro MUST be 
translated into YANG notification statements as detailed below. 


1. NOTIFICATION-TYPE Translation Rules 


The name of the NOTIFICATION-TYPE macro invocation is used as the 
name of the generated notification statement. The clauses of the 
NOTIFICATION-TYPE macro are mapped to YANG statements embedded in the 
notification statement as follows. 


o The SMIv2 OBJECTS clause is mapped to a sequence of YANG 
containers. For each object listed in the OBJECTS clause value, a 
YANG container statement is generated. The name of this container 
is the string "object-<n>", where <n> is the position of the 
object in the value of the OBJECTS clause (first element has 
position 1). If the current object belongs to a conceptual table, 
then a sequence of leaf statements is generated for each INDEX 
object of the conceptual table. These leafs are named after the 
INDEX objects and of type leafref. Finally, a leaf statement is 
generated named after the current object. If the current object 
has a MAX-ACCESS of "read-only", "“read-write", or "“read-create", 
then the generated leaf is of type leafref. Otherwise, if the 
current object has a MAX-ACCESS of "accessible-for-notify", then a 
leaf is generated, following the steps in Section 7.1. 


o The SMIv2 STATUS clause is mapped to the YANG status statement. 
The generation of the YANG status statement is skipped if the 
value of the STATUS clause is current. 


o The SMIv2 DESCRIPTION clause is mapped to the YANG description 
statement. 


o The SMIv2 REFERENCE clause is mapped to the YANG reference 
statement. 


o The value of the SMIv2 NOTIFICATION-TYPE macro invocation is 
translated into an smiv2:oid statement. Refer to the YANG 
extension defined in Section 10. 
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9.2. Example: linkDown NOTIFICATION-TYPE of IF-MIB 


The translation of the linkDown notification of the IF-MIB [RFC2863] 
is shown below. 


notification linkDown { 

description 
"A linkDown trap signifies that the SNMP entity, acting in 
an agent role, has detected that the ifOperStatus object for 
one of its communication links is about to enter the down 
state from some other state (but not from the notPresent 
state). This other state is indicated by the included value 
of ifOperStatus."; 

Smiv2 oid. 91 23:64. 630 Le lest 


container object-1 { 
leaf ifIndex { 
type leafref { 
path "/if-mib:IF-MIB/if-mib:ifTable" + 
"/if-mib:ifEntry/if-mib:ifIndex"; 


} 


container object-2 { 
leaf ifIndex { 
type leafref { 
path "/if-mib:IF-MIB/if-mib:ifTable" + 
"/if-mib:ifEntry/if-mib:ifIndex"; 
} 
} 
leaf ifAdminStatus { 
type leafref { 
path "/if-mib:IF-MIB/if-mib:ifTable" + 
"/if-mib:ifEntry/if-mib:ifAdminStatus"; 


} 


container object-3 { 
leaf ifIndex { 
type leafref { 
path "/if-mib:IF-MIB/if-mib:ifTable" + 
"/if-mib:ifEntry/if-mib:ifIndex"; 
} 
} 
leaf ifOperStatus { 
type leafref { 
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path "/if-mib:IF-MIB/if-mib:ifTable" + 
"/if-mib:ifEntry/if-mib:ifOperStatus"; 


} 
10. YANG Language Extension Definition 


This section defines some YANG extension statements that can be used 
to capture some information present in SMIv2 modules that is not 
translated into core YANG statements. The YANG module references 
[RFC2578] and [RFC2579]. 


<CODE BEGINS> file "ietf-yang-smiv2@2012-06-22.yang" 
module ietf-yang-smiv2 { 


namespace "urn:ietf:params:xml:ns:yang:ietf-yang-smiv2"; 
prefix "smiv2"; 


organization 
"TETF NETMOD (NETCONF Data Modeling Language) Working Group"; 


contact 
"WG Web: <http://tools.ietf£.org/wg/netmod/> 
WG List: <mailto:netmod@ietf.org> 


WG Chair: David Kessens 
<mailto:david.kessens@nsn.com> 


WG Chair: Juergen Schoenwaelder 
<mailto:j.schoenwaelder@jacobs-university.de> 


Editor: Juergen Schoenwaelder 
<mailto:j.schoenwaelder@jacobs-university.de>"; 


description 
"This module defines YANG extensions that are used to translate 
SMIv2 concepts into YANG. 


Copyright (c) 2012 IETF Trust and the persons identified as 
authors of the code. All rights reserved. 


Redistribution and use in source and binary forms, with or 
without modification, is permitted pursuant to, and subject 
to the license terms contained in, the Simplified BSD License 
set forth in Section 4.c of the IETF Trust’s Legal Provisions 
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Relating to IETF Documents 
(http://trustee.ietf.org/license-info). 


This version of this YANG module is part of RFC 6643; see 
the RFC itself for full legal notices."; 


revision 2012-06-22 { 
description 
"Initial revision."; 
reference 
"RFC 6643: Translation of Structure of Management Information 
Version 2 (SMIv2) MIB Modules to YANG Modules"; 
} 


identity object-identity { 
description 
"Base identity for all SMIv2 OBJECT-IDENTITYs."; 
} 


typedef opaque { 
type binary; 
description 
"The Opaque type supports the capability to pass arbitrary ASN.1 
syntax. A value is encoded using the ASN.1 Basic Encoding Rules 
into a string of octets. This, in turn, is encoded as an OCTET 
STRING, in effect ’double-wrapping’ the original ASN.1 value. 


In the value set and its semantics, this type is equivalent to 
the Opaque type of the SMIv2. This type exists in the SMIv2 
solely for backward-compatibility reasons and this is also 
true for this YANG data type."; 

reference 
"RFC 2578: Structure of Management Information Version 2 (SMIv2)"; 


} 


extension display-hint { 
argument "format"; 
description 
"The display-hint statement takes as an argument the DISPLAY-HINT 
assigned to an SMIv2 textual convention."; 
reference 
"RFC 2579: Textual Conventions for SMIv2"; 
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extension max-access { 
argument "access"; 
description 
"The max-access statement takes as an argument the MAX-ACCESS 
assigned to an SMIv2 object definition. 


The MAX-ACCESS value is SMIv2 specific and has no impact on 
the access provided to YANG objects through protocols such 
as NETCONF."; 
reference 
"RFC 2578: Structure of Management Information Version 2 (SMIv2)"; 


} 


extension defval { 

argument "value"; 

description 
"The defval statement takes as an argument a default value 
defined by an SMIv2 DEFVAL clause. Note that the value is in 
the SMIv2 value space defined by the SMIv2 syntax of the 
corresponding object and not in the YANG value space 
defined by the corresponding YANG data type."; 

reference 
"RFC 2578: Structure of Management Information Version 2 (SMIv2)"; 


} 


extension implied { 

argument "index"; 

description 
"If an SMIv2 INDEX object is preceded by the IMPLIED keyword, then 
the implied statement is present in the YANG module and takes as 
an argument the name of the IMPLIED index object."; 

reference 
"RFC 2578: Structure of Management Information Version 2 (SMIv2)"; 


} 


extension alias { 

argument "descriptor"; 

description 
"The alias statement introduces an SMIv2 descriptor. The body of 
the alias statement is expected to contain an oid statement that 
provides the numeric OID associated with the descriptor."; 

reference 
"RFC 2578: Structure of Management Information Version 2 (SMIv2)"; 
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Ll 


extension oid { 

argument "value"; 

description 
"The oid statement takes as an argument the object identifier 
assigned to an SMIv2 definition. The object identifier value 
is written in decimal dotted notation."; 

reference 
"RFC 2578: Structure of Management Information Version 2 (SMIv2)"; 


} 


extension subid { 

argument "value"; 

description 
"Ihe subid statement takes as an argument the last sub-identifier 
of the object identifier assigned to an SMIv2 definition. The 
sub-identifier value is a single positive decimal natural number. 
The subid statement may not be used as a substatement to any 
top-level node in a YANG document. The subid substatement may 
be used only as a substatement to a node having a parent node 
defined with either an smiv2:oid or smiv2:subid substatement."; 

reference 
"RFC 2578: Structure of Management Information Version 2 (SMIv2)"; 


<CODE ENDS> 
Implementing Configuration Data Nodes 


The result of the translation of SMIv2 MIB modules into YANG modules, 
even if SMIv2 objects are read-write or read-create, consists of 
read-only (config false) YANG objects. One reason is that the 
persistency models of the underlying protocols, SNMP and NETCONF, are 
quite different. With SNMP, the persistency of a writable object 
depends either on the object definition itself (i.e., the text in the 
DESCRIPTION clause) or the persistency properties of the conceptual 
row it is part of, sometimes controlled via a columnar object using 
the StorageType textual convention. With NETCONF, the persistency of 
configuration objects is determined by the properties of the 
underlying datastore. Furthermore, NETCONF as defined in [RFC6241] 
does not provide a standard operation to modify operational state. 
The <edit-config> and <copy-config> operations only manipulate 
configuration data. As a consequence of these considerations, it is 
not possible to generate YANG configuration data nodes from SMIv2 
definitions in an automated way. 
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However, for selected SMIv2 objects where the SNMP and NETCONF 
persistency semantics are consistent, implementations may choose to 
implement some YANG data nodes generated from SMIv2 definitions as 
configuration data nodes. Such a deviation from the generated read- 
only YANG module should be formally documented in the form of a 
separate YANG module that uses YANG deviation statements to change 
the config property of the data nodes implemented as configuration 
data nodes from false to true. Deviations that change the config 
false property to true without any other changes to the semantics of 
the data node do not affect the compliance with the YANG module 
generated from an SMIv2 module. 


11.1. Example: addressMapControlTable of RMON2-MIB 


The following example demonstrates how certain columnar objects of 
the addressMapControlTable of the RMON2-MIB [RFC4502] can be turned 
into YANG configuration data nodes. Note that YANG deviations affect 
the property of the target node only and are not inherited downwards. 


module acme-RMON2-MIB-deviations { 


namespace "http://acme.example.com/RMON2-MIB-deviations"; 
prefix "acme-rmon2-devs"; 


import RMON2-MIB { 
prefix "rmon2-mib"; 
revision-date 2006-05-02; 
} 


revision 2012-01-11 { 
description 
"First version."; 


} 


deviation "/rmon2-mib:RMON2-MIB" { 
deviate replace { 
config true; 
} 
} 


deviation "/rmon2-mib:RMON2-MIB/" 
+ "rmon2-mib:addressMapControlTable" { 
deviate replace { 
config true; 


} 
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deviation "/rmon2-mib:RMON2-MIB/" 
+ "rmon2-mib:addressMapControlTable/" 
+ "rmon2-mib:addressMapControlEntry" { 
deviate replace { 
config true; 
} 
} 


deviation "/rmon2-mib:RMON2-MIB/" 
+ "rmon2-mib:addressMapControlTable/" 
+ "rmon2-mib:addressMapControlEntry/" 
+ "rmon2-mib:addressMapControliIndex" { 
deviate replace { 
config true; 
} 
} 


deviation "/rmon2-mib:RMON2-MIB/" 
+ "rmon2-mib:addressMapControlTable/" 
+ "rmon2-mib:addressMapControlEntry/" 
+ "rmon2-mib:addressMapControlDataSource" { 
deviate replace { 
config true; 
} 
} 


deviation "/rmon2-mib:RMON2-MIB/" 
+ "rmon2-mib:addressMapControlTable/" 
+ "rmon2-mib:addressMapControlEntry/" 
+ "rmon2-mib:addressMapControlOwner" { 
deviate replace { 
config true; 


} 


} 
A NETCONF server that implements the RMON2-MIB module with these 


deviations would advertise the following capabilities in its <hello> 
message (where whitespace has been added for readability): 
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<capability> 
urn:ietf:params:xml:ns:yang:smiv2:RMON2-MIB? 
module=RMON2-MIBé&amp; 
revision=2006-05-02éamp; 
deviations=acme-RMON2-MIB-deviations 
</capability> 
<capability> 
http://acme.example.com/RMON2-MIB-deviations? 
module=acme-RMON2-MIB-deviationsé&amp; 
revision=2012-01-11 
</capability> 


IANA Considerations 


This document registers two URIs in the IETF XML registry [RFC3688]. 
Following the format in RFC 3688, the following registrations have 
been made. 


URI: urn:ietf:params:xml:ins:yang:ietf-yang-smiv2 
Registrant Contact: The NETMOD WG of the IETF. 


XML: N/A, the requested URI is an XML namespace. 


URI: urn:ietf:params:xml:ins:yang:smiv2 
Registrant Contact: The NETMOD WG of the IETF. 


XML: N/A, the requested URI is an XML namespace. 


This document registers a YANG module in the YANG Module Names 
registry [RFC6020]. 


Name: ietf-yang-smiv2 

Namespace: urn:ietf:params:xml:ns:yang:ietf-yang-smiv2 
Prefix: smiv2 

Reference: RFC 6643 


Security Considerations 


This document defines a translation of SMIv2 MIB modules into YANG 
modules, enabling read-only (config false) access to data objects 
defined in SMIv2 MIB modules via NETCONF. The translation itself has 
no security impact on the Internet. 
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Users of YANG data models generated from SMIv2 data models that have 


been published in the RFC series are advised 


to consult the security 


considerations of the respective RFCs. The security considerations 


of RFCs containing SMIv2 data models explain 
sensitive and important to protect. NETCONF 
make use of the NETCONF access control model 
the specification of access control rules to 
sensitive information. 
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Appendix A. 


RFC 6643 


Mapping of Well-Known Types 


Translation of SMIv2 to YANG 


(Normative) 


July 2012 


This normative appendix describes the mapping of SMIv2 types to YANG 
types. The mapping is fully consistent with Tables 1 and 2 of 


[RFC6021]. 


SMIv2 Type: 
YANG Type: 


SMIv2 Type: 
YANG Type: 


SMIv2 Type: 
YANG Type: 


SMIv2 Type: 
YANG Type: 


SMIv2 Type: 
YANG Type: 


SMIv2 Type: 
YANG Module: 
YANG Type: 


SMIv2 Module: 


SMIv2 Type: 
YANG Type: 


SMIv2 Module: 


SMIv2 Type: 
YANG Module: 
YANG Type: 


SMIv2 Module: 


SMIv2 Type: 
YANG Module: 
YANG Type: 
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SMIv2 Module: 


SMIv2 Module: 


SMIv2 Module: 


SMIv2 Module: 


SMIv2 Module: 


SMIv2 Module: 


SNMPv2-SMI 


enumeration 


SNMPv2-SMI 


int32 


SNMP v2-SMI 
Integer32 
int32 


SNMPv2-SMI 


OCTET STRING (used as a binary string) 


binary 


SNMPv2-SMI 


INTEGER (used as an enumeration) 


INTEGER (used as a numeric type) 


OCTET STRING (used to hold UTF-8 or ASCII characters) 


string 


SNMPv2-SMI 

OBJECT IDENTIFIER 
ietf-yang-types 
object-—identifier-128 


SNMPv2-SMI 
BITS 
bits 


SNMPv2-SMI 
IpAddress 
ietf-inet-types 
ipv4-address 


SNMPv2-SMI 
Counter32 
ietf-yang-types 
counter32 
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SMIv2 Type: 
YANG Module: 
YANG Type: 


SMIv2 Module: 


SMIv2 Type: 
YANG Module: 
YANG Type: 


SMIv2 Module: 


SMIv2 Type: 
YANG Module: 
YANG Type: 


SMIv2 Module: 


SMIv2 Type: 
YANG Type: 


SMIv2 Module: 


SMIv2 Type: 
YANG Module: 
YANG Type: 


SMIv2 Module: 


SMIv2 Type: 
YANG Module: 
YANG Type: 


SMIv2 Module: 


SMIv2 Type: 
YANG Module: 
YANG Type: 


SMIv2 Module: 


SMIv2 Type: 
YANG Type: 


SMIv2 Module: 


SMIv2 Type: 
YANG Module: 
YANG Type: 


SMIv2 Module: 


SMIv2 Type: 
YANG Module: 
YANG Type: 
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SNMPv2-SMI 
Gauge32 
ietf-yang-types 
gauge32 


SNMPv2-SMI 
TimeTicks 
ietf-yang-types 
timeticks 


SNMPv2-SMI 
Counter64 
ietf-yang-types 
counter64 


SNMPv2-SMI 
Unsigned32 
uint32 


SNMPv2-SMI 
Opaque 
ietf-yang-smiv2 
opaque 


SNMPv2-TC 
PhysAddress 
ietf-yang-types 
phys-address 


SNMPv2-TC 
MacAddress 
ietf-yang-types 
mac-—address 


SNMPv2-TC 
TruthValue 
boolean 


SNMPv2-TC 
TimeStamp 
ietf-yang-types 
timestamp 


RMON2-MIB 
ZeroBasedCounter32 
ietf-yang-types 
zero-based-counter32 
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HCNUM-TC 
ZeroBasedCounter64 


SMIv2 Type: 
YANG Module: 


YANG Type: 


SMIv2 Module: 
SMIv2 Type: 
YANG Module: 


YANG Type: 


SMIv2 Module: 
SMIv2 Type: 
YANG Module: 


YANG Type: 


SMIv2 Module: 
SMIv2 Type: 
YANG Module: 


YANG Type: 


SMIv2 Module: 
SMIv2 Type: 
YANG Module: 


YANG Type: 


SMIv2 Module: 
SMIv2 Type: 
YANG Module: 


YANG Type: 


SMIv2 Module: 
SMIv2 Type: 
YANG Module: 


YANG Type: 


SMIv2 Module: 
SMIv2 Type: 
YANG Module: 


YANG Type: 
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ietf-yang-types 
zero-based-counter64 


HCNUM-TC 
CounterBasedGauge64 
ietf-yang-types 
gauge6é4 


INET-ADDRESS-—MIB 
InetAutonomousSystemNumber 
ietf-inet-types 

as-number 


INET-ADDRESS-MIB 
InetVersion 
ietf-inet-types 
ip-version 


INET-ADDRESS-MIB 
InetPortNumber 
ietf-inet-types 
port-—number 


DIFFSERV-DSCP-TC 
Dscp 
ietf-inet-types 
dscp 


IPV6—-FLOW-LABEL-MIB 
IPv6FlowLabel 
ietf-inet-types 
ipvé-flow-label 


URI-TC-MIB 

Uri 
ietf-inet-types 
uri 


Module Prefix Generation (Informative) 


July 2012 


This section describes an algorithm to generate module prefixes to be 


used in the import statements. 
algorithm is a set of prefixes 


The input of the prefix generation 
(usually derived from imported module 


names) and a specific module name to be converted into a prefix. The 
algorithm described below produces a prefix for the given module name 
that is unique within the set of prefixes. 


Schoenwaelder 
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+----------------- +-------- + 
| YANG Module | Prefix | 
+----------------- +-------- + 
| ietf-yang-types | yang | 
| ietf-inet-types | inet 

| ietf-yang-smiv2 | smiv2 | 
+----------------- +------—- + 


Table 1: Special Prefixes For Well-Known YANG Modules 


o First, some predefined translations mapping well-known YANG 
modules to short prefixes are tried (see Table 1). If a fixed 
translation rule exists and leads to a conflict-free prefix, then 
the fixed translation is used. 


o Otherwise, prefixes are generated by tokenizing a YANG module 
name, using hyphens as token separators. The tokens derived from 
the module name are converted to lowercase characters. The prefix 
then becomes the shortest sequence of tokens concatenated using 
hyphens as separators, which includes at least two tokens and 
which is unique among all prefixes used in the YANG module. 


In the worst case, the prefix derived from an SMIv2 module name 
becomes the SMIv2 module name translated to lowercase. But on 
average, much shorter prefixes are generated. 
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